home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
lists
/
gem
/
l_1199
/
1059
< prev
next >
Wrap
Internet Message Format
|
1994-08-27
|
4KB
Date: Wed, 27 Jul 1994 00:43:08 -0400 (EDT)
From: Timothy Miller <millert@undergrad.csee.usf.edu>
Subject: GEM, etc.
To: gem-list@world.std.com
In-Reply-To: <m0qSvfr-0000Q5C@sdf.lonestar.org>
Message-Id: <Pine.3.87.9407270008.D12152-0100000@grad>
Mime-Version: 1.0
Precedence: bulk
Gem-List people:
Well, after much thought, I have decided to abandon the German
user-interface attitude of so overloading the interface with [sometimes
marginally useful] features that the program becomes unusable.
Instead, I am going to stick to a sensible, useful interfacing attitude
that aloows both the developer and the user to get work done in a
reasonable amount of time.
I see absolutely no point in going through all the trouble of adding
countless features and options, 90% of which will not be used in any
particular situation. I want a window-library that makes my life easy
with documentation that takes me less than a week to read and understand,
well-commented, readable code, and simple bindings.
I see no point in absolutely abandoning the GEM style. It makes sense to
make some modifications, yet some of the things you people are talking
about like sending key-presses to a background window are not only hard
to implement and counter-intuitive, but possibly DANGEROUS. I will not
send keypresses to a background window, and unless it's absolutely
necessary, I don't see any point in sending mouse-clicks to a background
window either. It's just not GEM and it will only confuse and frustrate
people.
I see no point in screwing with GEM's top-window-had-focus method. A
tool bar in a background window doesn't, as far as I'm concerned, have
focus when you click on it, so it's just fine with me. I do not like
giving focus to anything other than the top window. The X-windows method
is OK, but we're not using Xwindows... we're using GEM. Don't forget that.
I want users to like my applications. I want users to be able to use my
applications. Therefore, I will give the user only what he needs to be
able to accomplish his task effectively.
I am writing a window library. At the present it is about 20k. Already,
it cuts userinterface development for me into a small fraction of the
time it took before. It sets things up for me, does amodal dialogs, and
handles and directs window events automatically for me. It also makes
any application that runs under it a little more object oriented,
treating each window as a seperate object and giving the application
simple means to handle data independantly for each window.
With that, I have to ask what is in some of these other libraries that
take up over 200k? Loads and loads of more features.... most of which
someone looking to get work done would never use.
My library will continue to grow, but I doubt it will grow to more than
50k, and I will always strive to make it simpler and simpler to use while
it gets more and more powerful.
Evan:
]========================================================================
]handling clicks on the desktop. The point was to simulate WF_BEVENT in
]normal TOS. With normal TOS, if I click on a window, the window gets a
]WF_TOPPED message. Since I want to avoid that, I have to handle mouse
]========================================================================
]
]No, you just convert the WF_TOPPED message to button clicks. You
]can't do drags and such under normal TOS from a background window, unless
]you use the right button.
Am I not getting my point across? I want to do drags in background
windows in normal TOS. I KNOW how to convert WF_TOPPED messages into
button clicks. I'm already doing it! I want to do drags too.
BTW, I'm using a Falcon 030.
]As to where to put it, no one has even agreed to the above. They are
]still arguing about ^A and trying to vote on it. Damn stupid to vote
]on ^A when you can configure it instead.
It's not stupid. For one thing, I do not like the config file.
Secondly, if anyone uses Ctrl-A for select all, they're going to be in a
mess without a lot of hacking. It's just TOO EASY to hit Ctrl-A, and I
don't want something as dangerous as Select-All assigned to it. It's
perfectly logical.
Something dangerously easy to hit like Ctrl-A should have something
totally harmess assigned to it like Redraw-window.